Subject: RFC issues/comments after the DLSw V1 Interoperability Test

From: "Peter W. Gayek" <[email-masked]>
Date: Fri, 27 Oct 95 15:41:59 EDT

Here are some comments from the IBM team about the list Allen posted:

ISSUEs:
- Should a non-2067 write port be allowed?
- Capabilities Exchange error handling
- Vendor context CV
- NetBIOS - RII bit in SSP header MAC addresses

We agree with the stated resolution for all the above issues.

- Fill in of NetBIOS MAC/LLC header

For the length in the RI control field, our feeling is just to leave
it at what was in the trigger frame and not bump it up to 18 for the
pad.  This was left open in the proposal.

- Vendor ID. This number is the IEEE assigned number but some vendors
are having difficulty in obtaining one.

Using an OID would require code changes and was already voted down by
the RIG.  Allowing zero would be ok with us if there are companies
that don't want to purchase an OUI ($1000, I checked with IEEE).

---------------------------------------------------------------------------
>COMMENTS/QUESTIONS ON THE RFC (I believe these were already posted):
>
>1 - page 27 : 5.2.1. DISCONNECTED State
>  In the case of reception of broadcast DLC_XID, the action is to send
>  CANUREACH_ex. What will happen when ICANREACH_ex arrives? Do we
>have to  send XIDFRAME to the partner then or was this DLC_XID used
>just to reach  the topology table?

Since broadcast XIDs go to the null SAP, setting up a circuit to send
XIDFRAME on would require guessing about the DSAP, and this is what
1795 is trying to avoid.  So it seems that the appropriate ICR_ex
action would be to send XID response to the origin station (I think
this would most likely be an 802.2-format XID).

>
>2 - page 27 : 5.2.1. DISCONNECTED State
>  In the case of reception of DLC_CONTACTED, don't we have to start
>  CS_TIMER as well as for reception of non broadcast DLC_XID?

Yes, this seems like an omission from the spec that should be there.

>
>3 - page 28 : 5.2.2. RESOLVE_PENDING State
>  Perhaps XPORT_FAILURE must not be ignored! In this case, a suggestion
>  would be to send DLC_HALT_DL and then to change for
>HALT_PENDING_NOACK  state.

This seems to be the appropriate action.

>
>4 - page 29 : 5.2.3. CIRCUIT_START State
>  In the case of reception of ICANREACH_cs, there is a reference to a note
>  that doesn't exist anymore.

True.  The appropriate text to reference seems to start with the 3rd
sentence in the 2nd paragraph below the FSM.

>
>5 - page 29 : 5.2.3. CIRCUIT_START State
>  In the case of reception of CANUREACH_cs for circuit in opposite
>  direction, we may add a DLC_HALT_DL for the circuit which was in
>  CIRCUIT_START state.

Yes it seems that this should be added.

>
>6 - page 29 : 5.2.3. CIRCUIT_START State
>  In the case of CS_TIMER_EXP or XPORT_FAILURE, we may send a
>DLC_HALT_DL and change to HALT_PENDING_NOACK state in order to
>free the circuit.

Yes it seems that this should be added.

>
>7 - page 30 : 5.2.4. CIRCUIT_PENDING State
>  What happens if REACH_ACK doesn't arrive? Perhaps would it be useful
>to handle a timer in this state like in CIRCUIT_START state.

It should be up to the implementation how to handle cases like this
where required responses don't arrive.  The circuit-start timer was
added only because no response was required and we are setting up
dedicated resources.

>
>8 - page 36 : 5.2.10. DISCONNECT_PENDING State
>  What happens if DL_HALTED doesn't arrive?  Perhaps would it be useful
>to handle a timer in this state too.

Same as #7, we feel the FSM doesn't need to specify this.

>
>9 - page 39 : 5.3. NetBIOS Datagrams
>  Why a NB_Status_Response must be sent to all remote DLSw in order to
>a specific partner?

We agree, it should only go to one partner if you know where the status_
query came from.

>
>10 - page 42 : 5.4.1.2. SENT_EX State
>  What happens if ICANREACH_ex never arrives? Do we have to handle a
>timer in this state or to accept that a DLC_ERROR arrives to free the
>  "circuit"?

An implementation would probably want a timer, but we feel that since
this is just exploration, it would be inappropriate to add this to the
FSM.  There is no circuit state, and explorer control block management
seems it should be an implementation concern.

>
>11 - page 43 : 5.4.1.3. RECEIVED_EX State
>  What happens if DLC_RESOLVED never arrives? Do we have to handle a
>timer in this state or to accept that a DLC_ERROR arrives to free the
>  "circuit"?

Same as #10.

>
>12 - page 42 : 5.4.2..2. SENT_EX State
>  What happens if NETBIOS_NR_ex never arrives? In this case, the only
>  solution is to handle a timer...
>  The same situation may happen in RECEIVED_EX State if the datagram
>  NAME_RECOGNIZED does't arrive as well as in SENT_REC_EX State.

Same as #10.

>
>13 - page 39 : 5.4.2.2. SENT_EX State
>  Do the words "different local session number" mean "different response
>  correlator"? (in NAME_QUERY Frame, no field contains a session number)
>

We agree, "different response correlator" is the right wording.

>14 - page 83 : 8.7.1..6. A frame arrives from sender
>  The following sequence is incorrect :
>    IF NOT GrantDelayed THEN
>      IF GrantedUnits <= CurrentWindow THEN
>        IF FCACKOwed THEN
>          Protocol Violation
>        ELSE
>          Repeat Window Operator
>        ENDIF
>      ENDIF
>    ENDIF
>
>  To illustrate the problem, here is the following example (Window = 3):
>
>       Granted Units                               Granted Units
>         for Sender                                for Receiver
>            0                                           0
>            3              <---------FCIND(Rpt)         3
>            2              FCACK-------------->         2
>            2                       -FCIND(Rpt)         5
>            1              DATA-----|--------->         4
>            0              DATA-----|--------->         3****
>            3              <---------
>            2              FCACK-------------->
>
>  **** : at this time GrantedUnits = 3 and is <= CurrentWindow;
>         furthermore, FCACKOwed = TRUE, so according to the algorithm,
>         there is Protocol Violation : not for the Sender.

We agree, this seems to be a bug in the current description.

>
>  The following algorithm which works like in section 8.7.2.8 may be a
>  solution :
>
>    IF NOT GrantDelayed THEN
>      IF FCACKOwed THEN
>        IF GrantedUnits < CurrentWindow THEN
>          Protocol Violation
>        ENDIF
>      ELSE
>        IF GrantedUnits <= CurrentWindow THEN
>          Repeat Window Operator
>        ENDIF
>      ENDIF
>    ENDIF

This seems like a valid solution for fixed pacing.  Maybe Shannon
would want to check this out and see if it fits with the intent of
his examples.

>
>15 - page 88 and 89 : 8.8.3. Example Reset Window Flows
>  The last line for the 3 examples seems to be incorrect : for the
>  receiver, the window value is still 2 and the GrantedUnits value is 1.
>

We agree this is wrong and should be corrected.

-------------------
Peter Gayek
IBM Corp.